REMARKS 



Pending Claims: 

Claims 1-20 are currently pending in this application. Claim 9 has not been 
altered since filing. Claims 1, 2-7, 10-17 are amended by this response. Claims 2 and 8 
are canceled. Claims 18-20 have been added. Entry of these amendments is respectfully 
requested. 

Amendment to Specification: 

Amendments have been made to the specification to correct minor spelling and 
grammatical errors, and to add a serial number for an incorporated U.S. patent 
application. 

Rejection under 35 U.S.C. §102 and §103 

Claims 1-5 and 10-17 were rejected as anticipated by O'Mahoney, "Electronic 
Payment Systems/' hereinafter referred to as "OM." Claims 6-9 were rejected as obvious 
over O'Mahoney in view of Strong, U.S. Pat. No. 6,167,523. In particular, OM is cited as 
disclosing a digital token (or "scrip ") having a user identifier, a monetary value, and a 
"vendor identifier." OM's vendor ID identifies the vendor to whom the scrip is offered 
in exchange for services or information (OM p. 194 sec. 7.1.1.2, figs. 7.2 — 7.4). Strong is 
cited as disclosing the use of a computer registry for service information storage. 

In response to this rejection, the pending claims have been extensively amended 
to more particularly claim the present invention. Claim 1 has been amended to 
incorporate claim 2, and claim 2 has been canceled. The language of claim 1 has also 
been made more consistent with that of subsequent claims. Claim 1 now discloses a 
token comprising a "a token-vendor identifier identifying a vendor that sold the token." 
As stated in the specification, "the token includes a token identifier and a customer or 
user identifier. In a system where more than one vendor sells tokens, a vendor identifier 
may also be included in the token." Specification, % 30. Since the token-vendor identifier 
identifies the distributor who sold the tokens to the user (Fig. 3), the token-vendor in 
amended claim 1 is analogous to the broker in the OM reference (being the party that 
sells the scrip), as opposed to the OM vendor (the party that accepts the scrip). In the 
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OM reference, the broker is not identified in scrip. Consequently amended claim 1 is no 
longer taught or suggested by the OM reference. 

This distinction is important when examining the functionality of the token of 
claim 1 in comparison to the OM scrip. In the OM disclosure, the user buys scrip from a 
broker. OM, Sec. 7.1.1.1. The OM scheme forbids a given piece of scrip from being used 
to make a purchase from any vendor except the one identified in the scrip. OM, Sec. 
7.1.2. The instant invention, on the other hand, permits a user to use a token to buy 
products or services from any participating seller of property or services. The token- 
vendor ID can be used to identify the token-vendor. The token-vendor maintains the 
balance of a token in the token-vendor database. The token-vendor can compensate the 
seller for a token originally purchased from that token-vendor that has been applied to 
a purchase by the user from the seller. 

Claim 3 is dependent on claim 1, and therefore is allowable. 

Claim 4 has been amended in a manner consistent with the amendment to claim 
1, such that a newly purchased token contains a token-vendor ID. 

Claim 5 has been amended for formal purposes not related to the prior art. It is 
dependent on claim 4, and therefore is allowable. 

Claims 6-20 are either new or have been clarified to include limitations related to 
a user license being tied to a computer system ID, which is not taught or suggest by the 
prior art. For clarity, the general concept of the scheme is outlined here, while the 
details are discussed in connection with particular claims. Before purchasing a token, a 
user of the present invention must obtain a user license that is stored on a user's 
computer. The user license contains a user ID as well as a computer system ID that 
uniquely identifies the computer. The user license may also include personal or 
financial information about the user. A newly purchased token includes a unique token 
ID and the same user ID found in the user license. When a customer tries to spend a 
token to make a purchase, the token ID in the request is matched against the token- 
vendor database, and the user ID in the token is tied to the user ID in the user license. 
As explained in the specification, this connection between a token and a user license 
specifically linked to a single computer helps protect the token against theft. 
Specification, % 80. Only a user with access to the actual computer associated with the 
user ID can use the tokens in the present invention. Specification, % 88. Furthermore, the 
present invention includes a user license restoration process that allows tokens to be 
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moved from one computer to another and to be reestablished if lost due to a computer 
malfunction. Specification, <n 70, 79, and 99-103. 

OM's solution to the theft prevention problem is very different, involving 
encryption of the transmission and the use of a "customer secret/' OM, § 7.1.11. OM 
does not utilize a user license structure separate from the scrip, and scrip is not tied to a 
particular user computer. In fact, if a hacker were to copy a piece of scrip from someone 
else's computer with knowledge of the customer secret, the OM scheme would never 
detect the theft. With the current invention, such a hacker would be unable to use the 
token unless the physical computer was also stolen along with the secret password used 
by the user. Specification, ^ 88. 

Claim 6 was rejected under 35 USC §103 over OM in view of Strong (U.S. patent 
6,167,523). Newly amended claim 6 requires "obtaining a user identifier from a user 
license previously stored on a user computer, the user license further including a 
computer system ID thereby tying the user license to a particular computer system/ 7 
The OM scheme does not utilize a user license nor does it tie the user license to the 
system ID of the user computer. The Strong reference is only relevant with respect to 
secure storage of information in a registry. Consequently, claim 6 should be considered 
allowable over the cited prior art. 

Claims 7 and 9 are allowable because they are dependent on claim 6. 
Furthermore, claim 7 now requires that a token include a "token-vendor identifier", a 
structure found nowhere in OM, as described above in connection with claim 1. 

Claim 10 is an independent claim for a "method of charging payment against a 
previously purchased digital token." As amended, it requires the "storing on a user 
computer having a computer identifier, a user license containing a user identifier and 
the computer identifier for the user computer." This is distinguishable from OM, which 
does not use computer identification for any purpose. 

Claim 11 is dependent on claim 10 and thus allowable. 

Independent claim 12, pertaining specifically to sales of digital licenses using 
digital tokens, has also been amended consistently with the protection scheme 
described previously. A user license is defined to contain a user identifier and a 
computer identifier. On installation of the user license, the computer identifier is set to 
contain characteristics uniquely identifying the user computer. A digital token is 
defined to contain a user identifier and a unique token identifier. When a token is 
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installed on a user computer, the user identifier is set to the user identifier in the user 
license. The token identifier is stored in a database along with its monetary balance. 
Again, OM does not disclose a protection scheme even slightly resembling this 
approach. 

Claims 13 and 14 depend from claim 12 and should be considered allowable for 
the same reasons as claim 12. 

Claim 15 is an amended claim for the structural elements that bind a token to a 
particular computer. In particular, claim 15 requires the user license on the user 
computer to contain a user ID and a computer ID; the token on the user computer to 
contain a user ID and a token ID; and the existence of a database in which token IDs are 
associated with the user ID. As explained above, this is not taught or suggested in any 
of the prior art references. 

Claim 16 is an amended independent claim for a " method for purchasing a 
digital token/ 7 It discloses "storing within a user license said user identifier on said 
computing device in association with a computer identifier including a set of 
characteristics uniquely identifying said computing device/' This user license clearly 
distinguishes claim 16 from the OM approach. 

Claim 17 is an amended independent claim for a "method of making a purchase 
via a previously purchased digital token/ 7 The method requires a computer on which is 
stored "user license containing a user identifier and a system identifier uniquely 
identifying the computer." The existence of this user license is enough to distinguish the 
approach from OM. 

Claims 18-20 are new claims supported in the specification. Each claim requires a 
token having a user identifier and a user license having the same user identifier and a 
computer or system identifier. These elements tie the token to a particular computer in a 
way not taught or suggested in the prior art. 
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CONCLUSION 

All of the claims remaining in this application should now be seen to be in 
condition for allowance. The prompt issuance of a notice to that effect is solicited. 



Respectfully submitted, 
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